Create a custom interview user experience

Create a custom interview user experience

What do you want to do?

Create the interview session

Add data to the interview iession

Retrieve Interview Engine screens

Investigate an Interview Engine goal

Integrate Interview Engine with an external data source

Generate an Interview Engine decision document

Retrieve Interview Engine commentary

Handle Interview Engine events

Install an Interview Engine plug-in

 

Before setting out to create an interview session, you should familiarize yourself with the Interview Engine by reading the topic. Understand the Interview Engine.

Create the interview session

The first step when working with the Interview Engine is to create an interview session; this is done as follows:

  1. Create and configure an EngineConfiguration object.
  2. Create an instance of the Interview Engine.
  3. Get the rulebase to be used.
  4. Create the interview session.

 

This is illustrated by the following code sample:

Add data to the interview session

There are two ways of adding/modifying data for an interview session:

Submit an interview screen

Add data directly to the session

Submit an interview screen

The most common way of adding data to an interview session is to do so by populating an interview screen and submitting it using the following method:

TransactionResult InterviewSession.submit(InterivewScreen screen)

 

Calls to this method trigger a transaction which attempts to submit the data contained on the screen in the rule session. The TransactionResult that is returned provides an indication as to whether the transaction succeeded or failed and a list of any errors, warnings and rule events that fired during the transaction.

Set input control values

InterviewScreens can contain instances of InterivewInputControl which are bound to a particular attribute. Adding values to the screen is simply a matter of calling the following on the InputInterviewControl and supplying the value corresponding to that controls attribute:

void setValue(Object v);

on the InputInterviewControl and supplying the value corresponding to that controls attribute.

The sample code that follows, illustrates how to add values to the following screen:

 

 

Add entities

The ContainmentRelationshipInterviewControl is the control that represents the creation of new entity instances during an interview. Entities, along with their relationships, can be added, edited and removed using the methods provided by this control. When created, this control will automatically be populated with the relevant entity instances currently held in the session. Each instance of the entity represented on the screen is encapsulated by EntityInstanceInterviewControl which, in turn, contains the list of controls bound to that entity instance.

The sample code that follows, illustrates how to add, delete and edit existing entity information for the following screen:

 

 

Add reference relationships

The ReferenceRelationshipInterviewControl represents a control that allows entity instances to be related together via a specified relationship. Unlike the ContainmentRelationshipInterviewControl it does not allow new instances of the relationship's target to be created. When created, the ReferenceRelationshipInterviewControl will be populated with the list of all possible targets of relationship, along with all relevant relationships already held in the session. Relationship instances can the be added or removed using the methods supplied by this control.

Add data directly to the session

The second way of modifying the data held in the interview session is via the following method:

TransactionResult InterviewSession.submit(InterviewUserData dataModel)

 

This method allows for data currently held in the system to be modified independently of a given screen model. Like the previous method the data contained in the InterviewUserData provided to this method is considered a single, atomic transaction.

Understand the InterviewUserData

The InterviewUserData is the Interview Engine's abstracted representation of the data currently held in the session. In the context of modifying data within the system, the user data model represents the delta of the changes that are to be performed in the transaction. In addition to the InterviewUserData object the Interview Engine's data model contains the following key classes:

 

Understand the InterviewEntityInstance

As demonstrated in Construct the InterviewUserData below,the InterviewEntityInstance object is the key building block when constructing the InterviewUserData, and all modification can be done through the InterviewEntityInstance.

Below is a class diagram of the InterviewEntityInstance with key class members. Note the following points when analyzing it:

 

 

 

Construct the InterviewUserData

Conceptually, building the InterviewUserData is commonly constructed as per the sequence below:

  1. An InterviewUserData is created
  2. Entity instances modifications are created and added into the InterviewUserData
    1. An entity instance is created
    2. The 'modification status' of the instance is set - add, delete, or existing
    3. If the instance's status is 'add' or 'existing', values of zero or more attributes of the instance is populated to define attribute modifications (no reason to modify attributes if the instance is to be deleted)
    4. The instance is added into the InterviewUserData

  3. Relationship modifications between the entity instances are create, using the source entity instance
    1. The relationship is determined
    2. The source and target entity instance are instantiated and accessible
    3. The relationship is created in the source entity instance, passing the name of the relationship, target entity instance and 'modification status' of add or delete.

 

When constructing the InterviewUserData with the above steps, the following behaviors need to be kept in mind:

 

The following sample code demonstrates the steps above. Note that for demonstration's sake, the code is simplified and does not incorporate best practices. See Modifying the instance data - sample code  for best practice techniques for constructing the InterviewUserData.

Technical information when constructing InterviewUserData

The following are key points to keep in mind when constructing the InterviewUserData:

Best practice

The fundamental idea underpinning all the best practice concepts below is that it is better to check for possible errors during the construction of the modifications, by checking the model of the modification data against the rulebase model.

Failure to check for errors during the construction of the modification will lead to the RuleSessionManager having errors when attempting to apply the modifications to the session. The RuleSessionManager has to then rollback if there are any errors. Rollbacks can potentially fail, which means the user loses all session data whereas handled errors during the 'construction' of the modifications can be properly handled by the developer.

The developer can check the modification data against the rulebase model data, but not the instance data in the session. Possible errors with instance data (for example, trying to add a duplicate entity instance) can only be discovered once the RuleSessionManager is actually applying the modifications.

 

Verify entity instance modifications

When creating an InterviewEntityInstance, check that the entity exists in the rulebase model.

Verify attribute value modifications

When adding attribute values to an InterviewEntityInstance, check that the attribute exists for the entity instance.

Adding the above attribute value was simple, because the attribute 'name' is a Text ruleengine datatype, and the corresponding Java/.NET type is String (see Formatter Plugin).

In the following sample code, we check the ruleengine datatype (HaleyType) of the attribute, and parse it accordingly from String format -> Object. A basic parser method (simpleParse) has been created which converts the String value to the correct Object value using the HaleyType of the attribute.

Verify relationship modifications

When adding relationship modifications, check that the entity of the source and target entity instances match the expected entity source/target of the relationship.

Best practice sample code

The following code samples show a conversion of the simple sample code found in Constructing InterviewUserData samples above, to best-practice.

Retrieve Interview Engine screens

Screens in the Interview Engine are managed the Screen Service which provides all the methods to retrieve each of the different screens found in an Interview.

Retrieve a question screen

The screen service provides the ability to return question screens by id, by attribute or by relationship, which is illustrated in the following example:

Retrieve a summary screen

Every interview has a default summary screen which can be accessed by calling:

ScreenService.getDefaultSummaryScreen()

If no default summary screen has been created, the Interview Engine will automatically generate one containing all the top level goals found in the Global Entity Instance. In the case where multiple summary screens have been authored, then non-default summary screens can retrieved by screen Id.

Retrieve a data review screen

Like summary screens, every interview also has a default data review screen which can be accessed by calling:

ScreenService.getDefaultDataReviewScreen()

The Interview Engine will automatically generate a default data review screen containing all user set data, arranged by entity instance, if one was not explicitly authored. If multiple data review screens have been authored, the non-default screens can be accessed by Id.

Retrieve a decision report screen

Retrieving decision reports in the Interview Engine are done by asking for a decision report screen for a particular attribute or relationship. The Screen Service provides the following methods retrieve a decision report screen:

Investigate an Interview Engine goal

The list of goals that are able to be investigated in Interview Session are managed by the Goal Service. The Goal Service provides the ability to return a goal based on ID or goal state. The goal service can also provide a list of all top level goals in the Interview Session. A top level goal is either a top level attribute instance or a flow goal.

Goals can also be accessed via the goal control(s) on a summary screen.

Conduct the interview

Having understood the fundamentals of how the Interview Engine works, conducting an interview is a straight forward process as shown in the following flow diagram:

 

Integrate the Interview Engine with an external data source

For information relating to the integration of the Interview Engine with an external data source, refer to Data Adaptor - Common Scenarios where pre-seeding and interview with data, saving data, auto-saving data and using the Data Adaptor to handle data integration are discussed.

See also:

Data Adaptor plugin overview

Create a Data Adaptor

Generate an Interview Engine decision document

Users require a transcript when going through any interview, so that they have:

 

The client system running the Web Determinations interview needs to be able to provide this, and also be able to define what data from the interview session is displayed in the transcript, and how it is displayed (layout).

Oracle Policy Modeling allows rulebase authors to create reports of the Web Determinations interview, accessible by the user from the Summary screen. With the report links, users can view and download information transcript about the interview session as a document.

The Document Generator plugin is an Engine Session plugin to the Interview Engine that allows plugin developers to generate those documents in any document type, and also define the document layout and which session data is displayed. A Document Generator is known by the document type it provides; for example, HTML, PDF, XML and so on.

By default, Web Determinations ships with two Document Generators for HTML and PDF. For more information about using these, see the topic, Use the default Document Generator.

Multiple Document Generators can be used together during a Web Determinations interview session, allowing users to view the interview transcript in various formats. This is different to other plugins where only one plugin can be used during an interview session; for example, Data Adaptor plugins.  Each Document Generator provides a specific document type, therefore it is imperative that all Document Generators registered during a Web Determinations interview, must provide unique document types.

Go to:

Document Generator plugin overview

See also:

Document Generator - sample code

Retrieve Interview Engine commentary

Some screens and attributes during a Web Determinations Interview are complex or ambiguous and need further explanation. The Commentary functionality in Web Determinations allows the rulebase author to provide extra information about screens and attributes, which can be accessed by the user during the interview when more information or explanation is required. The Commentary functionality also allows an external web page to be displayed as commentary.

When commentary is available for a screen or attribute, the attribute/screen label is rendered as a link that the user can click on to view the commentary information. By default, commentary is displayed in a frame to the right of the interview screen. Optionally, it is possible to configure Web Determinations to display commentary information in a new window (more about the configuration in Configuration files). Attributes and screens do not have to have commentary, and it is possible for a Web Determinations interview to have commentary available for some screens/attributes only.

Commentary plugins are Engine Session plugins that manage commentary in a Web Determinations interview. The main functionality is to determine whether commentary for a screen/attribute is available, and to be able to provide the commentary content to those screens/attributes when requested. Commentary plugins have the flexibility of being able to retrieve content from datasources accessible in a Java/.NET class, or returning a URL to be displayed in the commentary frame/window. The ability to return a URL allows Commentary plugins that can make use of a client's existing information webpages.

Web Determinations ships with a default Commentary plugin that uses commentary HTML files generated from Oracle Policy Modeling by the rulebase author. More about the default Commentary in Use the default commentary.

Like many other plugins, only one Commentary plugin can be registered per Web Determinations interview.

Go to:

Commentary plugin overview

See also:

Use the default commentary

Pseudo code

Sample code (DerbyCommentary)

Sample code (RedirectCommentary)

Configuration files

Handle Interview Engine events

For a description of the specific engine and platform events, including details about the objects contained by the events (accessible and modifiable by associated event handler implementations) and the mapping between the events and the event handler interfaces to be implemented by plugin classes in order to be registered as valid event handlers for the respective events, go to the topic, Events and event handlers.

Install an Interview Engine plug-in

For information regarding the installing and registering of Web Determinations extensions, refer to the topic Plugin loading, invocation and discovery.

See also:

Introduction to Web Determinations extensions

Web Determinations extensions - the technical details

Plugin loading, invocation and discovery